![[初学者向け] IAM 設計の観点解説とテンプレート化してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-7bf2dfb6b7a0dd9b7561e87b396ccdc3/018019c86ac567eceba7268550750d9f/aws-iam)
[初学者向け] IAM 設計の観点解説とテンプレート化してみた
2024.09.26はじめに
こんにちは、さすけです！
今回は「AWS の薄い本 IAM のマニアックな話」という書籍を読みながら実際に IAM ポリシーや IAM グループを作成、CloudFormation テンプレート化してみました。
私自身、IAM 設計の経験ゼロのため本ブログは初学者向けの内容となっています。一緒に頑張りましょ！！
IAM 設計で意識すべきこと
本書を参考にして、今回の検証では以下の5点を意識しました。
- IAM ポリシーは IAM グループにアタッチする
- IAM グループに IAM ユーザーを追加することでポリシーを適用させる
- 1つのカスタマーポリシーに役割を持たせ過ぎない
- CloudFormation コードが長くなり過ぎないようにする
- CloudFormation テンプレートには IAM ユーザーの作成を任せない
どれも基本的には 汎用性と管理のしやすさ を重要視しています。
文章だけでは、伝わりづらい部分も多いかと思いますので早速作っていきましょう！
IP 制限を設けた管理者ポリシー
IAM 設計の経験がないため、ひとまず簡単なポリシーを作成してみます。
実際に作成したカスタマーポリシー①は以下の通りです。（ポリシー名：AdminDenyTest）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"xxx.xxx.xxx.xxx/32"
]
}
},
"Resource": "*"
}
]
}
内容としては、特定の IP アドレス xxx.xxx.xxx.xxx/32 以外からのアクセスでは全ての権限を剥奪するというものになっています。
「許可ポリシーがないじゃないか」と思った方もいらっしゃるかと思います。
許可ポリシーについては、AWS 管理ポリシーの AdministratorAccess を付与します。拒否ポリシーが優先されるため、IP 制限が適用され xxx.xxx.xxx.xxx/32 以外からはアクセスが拒否されるようになります。
IAM グループを作成し、カスタマーポリシー①とAWS 管理ポリシーの AdministratorAccess を付与します。
その後、IAM ユーザーを作成し、先ほど作成した IAM グループに追加しましょう。
すると以下画像のように、ユーザーにポリシーが適用されます。
カスタマーポリシーの中に、許可ポリシーを追加して1つのカスタマーポリシーのみをアタッチしても良いのですが、複数の許可や拒否が1つのカスタマーポリシー内に入るということは、汎用性が下がり管理が煩雑になる可能性があります。
たとえば、上記のカスタマーポリシー①に許可ポリシーを追加した下記ポリシー②と比較して考えてみましょう。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"xxx.xxx.xxx.xxx/32"
]
}
},
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
2つのカスタマーポリシーを比較
上記のカスタマーポリシー①と②を使用できる場面を考えてみましょう。
まず①のユースケースとしては、多岐に渡るかと思います。
セキュリティ上、「特定の IP アドレス以外からのアクセスを制限したい」という要件は、管理者のみならず、開発者、ネットワーク管理者など、どのグループでもあり得ます。
その際に、IP 制限のみ切り出して作成しておいた①のカスタマーポリシーがあれば、①を各グループに付与することで 新しくカスタマーポリシーを作成する必要がなくなります。
では、カスタマーポリシー②ではどうでしょうか。
カスタマーポリシー②には Admin の許可ポリシーも付与されているため、管理者にしか使用できないポリシーになっているのです。
これでは開発者やネットワーク管理者に IP 制限を設けたい時に、それぞれ別のカスタマーポリシーを作成しなければならなくなりますよね。手間が増えてしまいます、、。
これはカスタマーポリシーを管理する上でも影響が出てきます。
たとえば「特定の IP アドレス」を変更したい場合を考えてみましょう。
①の場合では、ユーザーがどのグループに属していたとしても、IP 制限を①のみで設定しているため、カスタマーポリシー①の変更のみ で済みます。
それに比べて、②では汎用性が低いがために、各グループそれぞれに専用のカスタマーポリシーを作成してしまっており、それぞれに付与されている別々のカスタマーポリシーを全て書き換えなければいけなくなります。
CloudFormation でテンプレート作成
次に、CloudFormation でテンプレートを作成してみましょう。
これにより、マルチアカウントで運用する際に簡単に CloudFormation テンプレートからカスタマーポリシーと IAM グループを作成することができます。
AWSTemplateFormatVersion: '2010-09-09'
Description: IAM Test
Resources:
# IP 制限をかけるカスタマーポリシーの作成とグループへ付与
TestIAMPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: AdminDenyTest
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Deny
Action: '*'
Resource: '*'
Condition:
NotIpAddress:
aws:SourceIp:
- '8.8.8.8/32'
Groups:
- Ref: TestIAMGroup
# IAM グループの作成と管理者権限の付与
TestIAMGroup:
Type: AWS::IAM::Group
Properties:
GroupName: TestGroup
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AdministratorAccess
テンプレートは上記のようになります。
CloudFormation テンプレートでは、IAM 以外もさまざまな設定をテンプレート化できますが、全てを 1 つのテンプレートにまとめるとコードが長くなり、管理が煩雑になる可能性があります。
個人的には、上記のように IAM グループとそれに付与するポリシーのみでテンプレートを 1 つ作成しておくなど、細かくテンプレートを分けると管理がしやすいかと思います。（IAM ポリシーを作成する時と同じような観点ですね！）
また、IAM ユーザーの作成をテンプレートに記述していないのも 汎用性を高めるため です。
IAM ユーザーは一度作成してしまえばそれっきりです。ですので、IAM ユーザーの作成をテンプレート化するメリットは少なく、むしろテンプレートを展開した際に自動的に IAM ユーザーが作成されてしまうことから 使用場面を狭めてしまう可能性があります。
まとめ
さて、今回は「AWS の薄い本 IAM のマニアックな話」を参考に、簡単な IAM 設計を行ってみました。
本書は「マニアックな話」と題していますが、内容としては 基本的な IAM の概要と設計の観点を学べるもの になっていました。
本ブログで、IAM 設計に興味を持たれた方はぜひ「AWS の薄い本 IAM のマニアックな話」を一度お手に取って頂ければ楽しんでいただけるかと思います！
参考資料
アノテーション株式会社
アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。
